【レポート】AWS Summit Tokyo 2017: [AGC 旭硝子] クラウドで変わる。インフラ・データセンター・組織のありかた #AWSSummit

『AWS Summit Tokyo 2017』が2017年5月30日(火)〜6月2日(金)、グランドプリンスホテル新高輪 品川プリンスホテル アネックスタワーで開催されています。

当エントリでは、Day2 導入事例トラック 2のセッション、「［AGC 旭硝子］クラウドで変わる。インフラ・データセンター・組織のありかた」をレポートしたいと思います。

• AWS Summit Tokyo 2017（2017年5月30日～6月2日）｜AWS

セッション概要

当セッションの登壇者及び概要は以下の通りです。

セッションレポート

以下、セッションのレポートです。

AGC 旭硝子について

• 1907年創業
• 創業100年を超える
• 1日に1,8000トン、バチカン市国x3個分のガラスを毎日作っている
• 生産量は世界一

スピーカーについて

• 2011年中途入社
• 前職はSIerに8年ほど在籍
• AGCにうつってから6年
• AWS の PSA資格保持

2015年に続く2回目のAWS Summit登壇

• 2015年のAWS Summitで初登壇
• 当時のタイトルは「メインフレームからクラウドへ 〜クラウドで情シス文化を変える〜」
• 当時はAWSをガンガン使っていたわけではなく、これからガンガン使いますよと宣言しただけ
• 2年経ってクラウド化はどう進んだのか？その振り返りから始める

そのふりかえりから、本セッションを始める

AWSクラウド化の進捗

2015年発表当時

• 78インスタンス稼働
• 本番システムはなかった

2017年現在

• 452インスタンス稼働
• 基幹系→376
• 基幹外→76

• このサーバー台数を多いと思うかは業界による

  • ウェブ系であれば、何百、何千台のサーバーを動かしている
  • 製造業の基幹として考えると、そこそこの規模といえるのではないか
• 現在は2日に1台位のペースで増えている

まとめ

企画倒れにならずにAWS化が浸透している。

SAP移行について

• AGCでは多くのSAPシステムが稼働している
• 2016年1月に第1号のサービスイン
• 第2号は2017年6月にサービスイン予定
• 残りのSAPも順次移行予定

コストについて

• 2015年当時、AWSクラウド化に伴い、コストが落ちそうな気がすると言っていた
• 実際にコストを削減できたのか？
• SAPはオンプレ時代に比べ3割のコストダウンを達成
• AWS化によりDC費用・運用削減費用含めずにサーバーコストだけの比較で3割の削減
• DCのコストも含めると、削減率は更に増える

AGCのAWS移行戦略

ここからもっとスパイスのきいた話

• 標準化
• DC戦略
• クラウドx情シス

標準化

• AWSの基幹系：376インスタンス
• 62システムがAWS利用中(SAP、Oracleなど)
• 2週間に1回のペースでAWSにシステム移行する意思決定
• 適用業務・利用ソフトウェア・開発保守ベンダー すべてがバラバラ
• 移行対象システムはバラバラだけれども、一定のペースでAWS移行できている

超基幹特化型標準化

AGCの基幹システムのAWS移行方針

• 基幹ではセキュリティが超大事
• AWSをきちんと理解して100％使いこなせる人は、社員はおろかベンダーでも稀
• ガイドライン文書をベンダーに渡す方式はやっていない。
• ガイドラインを一度作成しても、更新されず、古新聞になりがち
• 過去のSIerの経験から、ガイドラインだけでは拘束力が不十分

ガイドラインではなく社内向けAWS利用環境サービス(“Alchemy”)を作成

• AWS ではなく Alchemy を用意しましたた、と社内に展開。
• AWSを生で触らせず、ワンクッション入れる

Alchemy とは？

• AGC 謹製のAWS利用環境
• 1アカウントに全システム集約
• セキュリティに関する設計・設定をユーザにさせない
• ユーザーにはOS以上だけの操作を許可する
  • NACL/IGW/サーバー作成などはユーザーができない。
• AWSコンソール作業は基本申請(EC2の起動・停止など限定的な権限だけ許可)
• 申請は昔ながらのExcel
• ユーザーからすると、仮想サーバーが渡され、その上で作業
• アプリ側からすると、オンプレ時代と同じでAWSを意識しなくてすむ
• インフラ管理はAWS上
• AWSサーバー管理はAWSインフラチームが管理する

使えるサービスを基幹で使いそうなものに限定

• EC2
• RDS
• S3

この3つができれば、基幹システムは作れる。

CloudAutomator でバックアップ・起動停止管理を行う

請求

• 請求先が事業部毎
• 関係会社にも請求出来るようにする
• 費用分割作業(請求代行)はアウトソーシング

本社以外の多くの企業が使いたいと言ってくれている

拡散性とクラウドらしさのトレードオフ

• AGCのクラウド移行は、サーバーをAWSに移行しただけ
• 拡張性(クラウドの移行のしやすさ)を優先し、クラウドらしさはあまりない
• 拡張性とクラウドらしさは0，1ではなく、パラメーターの振り方
• AGCはクラウドらしさよりも拡散性に大きくかじをきっている

なぜ拡張性を優先？

• ハードウェア資産を削減したい
• アプリ改修したくても、ハードウェアのリプレース時期に、アプリ改修に合わさざるをえないことも
• アプリ改修を依頼側からすれば、ハードウェアの減価償却はしったことではない
• 資産管理とアプリのライフサイクルを別にしたい

データセンター内のHW資産は減り続けている

クラウド時代に企業のデータセンターはどうあるべきか？

• 情シスは企業のカーストでは下
• データセンターを管理している挟持がある

プレAWS時代

• 社内のインフラの中核はデータセンター
• データセンターがハブ

ポストAWS時代

• DCとAWSやSaaSがつながっている
• 大事なデータがAWSやSaaSにたまっている
• DC の役割はへっている

「データのセンター」はどこ？

• データセンターはもはや「データのセンター」ではない
• 死守すべきはデータセンターではなくクラウドまでのWAN経路
• ネットワーク経路にコストをかけるべき

ネットワークセンター

• ネットワークセンターを利用して,各サービス・拠点とつながるようにした
• 新DCはフロア単位ではなく、ラック単位契約にした
• どんどんAWSに移行するから
• 2016年の6月から稼働

もとのDCはどうなったのか？

• 最後は分電盤だけが残った

まとめ

AWS移行により

• ハードウェアのリプレース
• DCの聖域化

がなくなった

クラウド x 情シス

クライド時代の情シスのあり方

• 「情シス不要論」でもりあがることも
• 「情シス不要論」でGoogle検索すると 41,700件 引っかかる
• 情シスの立場からすると、イラッとするが改めて考え直すと、主張は一理ある
• “情シス不要論”が出たことを情シスは歓迎すべき

Why Software is Eating the world

• もともとネットスケープを開発した Marc Andressenが Wall Street Journal で2011, Aug 20に発表
• https://www.wsj.com/articles/SB10001424053111903480904576512250915629460
• すべての産業がソフトウェアにくわれている
• 業種によらず、ソフトウェア化される
• Uber,AirBnBなど、この予言はだんだん本物らしくなっている
• ソフトウェアで勝てないと、今後は生き残れない雰囲気
• 情シスがやるべきは Change

どうChangeするのか?

• 会社によって変わるべき方向は違う
• AGCはどうしようとしているの？
• →PoCセンター

情シスにPoCセンター機能をインストール

• アイデア→PoC→うまくいったら大規模にシステム化
• アイデア、PoCまでは自社(内製化)
  • 契約社員、外注だとコスト・基幹的に難しい
  • 外注を使わず自社で素早く何度もやる。
• うまくいけば、そこから先は SIer or 内製
• AGCのような年功序列の会社は SIerと組んだ方がやりやすい

Changeできない3大理由

1.手軽にPoCする環境がない

• AWS が解決
  • AWSとDXでつながっている
  • 100台のサーバーもすぐに立ち上げられる

2.基幹の仕事が多くて暇がない

• AWS が解決
  • HWを消すほうにシフトし
  • HWの保守/運用が減る

3.アイデアが無い・開発したこと無い

• AWSを契約してもなんともならない。
• 去年、ちょっとしたバッチプログラム開発をやってみた。
• 基幹のマネージメントばかりをやってきた人に初めて開発をやらせたところ、残念なアウトプット
  • 別の会社に開発のお作法のトレーニングをお願いしている

トレーナー付き自社開発

• スプリント形式で実際の開発を行う
• スプリントの管理や開発のヘルプは協力会社にお願いしている
• はじめて3ヶ月たった
• ベンダー管理しかしていなかった人でも、実際にコードを書いて、Gitで修正できるようになった

AWS教育

• 業務・テクノロジーの両方の知識が必要
• 情シスは業務を知っているが、テクノロジーはしらない
• AWSの最低レベルの知識が何かはわからないので、アソシエイト取得をゴールに設定
• トレーニングを協力会社にお願い
• 情シスの20％が取得がゴール
• キャズムの谷で、取得者が20％を超えれば組織の文化が変わるのではないか

クラウドにして何が良かったの？

• 一番いいところは“Speed”
• なぜスピードが重要なのか?
• デジタライゼーションを推進したい

ビジネスに必要なもの

• 技術力
• 環境
• 時間
• 情熱 ← どろくさく、一番重要

情熱は大事

• 「情熱」がもえていられる時間には限りがある
• やりたいことをいつまでも追い続けられる人はレア
• ひらめいた、やりたいと思ったときにすぐ使える(=スピード感のある)インフラ・カルチャーがAWSにはある
• スタートアップとAWSの相性の良さもこのあたり

まとめ

AGCは今後もAWSを使ってビジネスを推進していく。

感想

歴史あるエンタープライズ企業でありながら、時代・価値観の変化に柔軟に対応し、ベンダー任せではなく、情報システム部が主導してシステムのあるべき姿を再定義し、クラウド化の計画と遂行を実践しているのが印象的でした。